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Abstract 


I  nteroperability  has  traditionally  been  considered  a  property  of  operational  systems, 
wheresystems  are  able  to  exchange  information  in  some  agreed-upon  fashion.  How¬ 
ever,  other  aspects  of  interoperability  areoften  overlooked.  This  report  introduces  one 
of  those  aspects— the  concept  of  programmatic  interoperability,  which  is  the  applica¬ 
tion  of  principles  of  interoperability  to  the  acquisition  management  of  systems.  It 
shows  how  programmatic  interoperability  contributes  to  fielding  interoperable  capa¬ 
bilities  and  relates  this  aspect  to  current  trends  such  as  network-centric  operations. 
The  report  also  discusses  the  orchestration  of  decisions  and  activities  that  are  appli- 
cableto  acquisition  in  a  system-of-systems  environment.  Finally,  the  report  suggests 
several  research  topics. 
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1  Introduction 


There  is  increased  emphasis— in  commercial  industry  and  government— on  moving 
toward  a  network-centric  perspective  to  provide  operational  capabilities  to  end  users. 
For  acquirers  and  developers,  this  perspective  shifts  the  view  from  an  individual  sys¬ 
tem  to  a  system-of-systems  environment  and  fundamentally  alters  the  nature  and 
extent  of  the  requi  rements  for  i  nteroperabi  I  ity.  We  use  the  phrase  system-of-systems 
environment,  not  systems-of-systems  acquisition.  The  former  term  describes  the  inte¬ 
gration  of  multiple  separate  acquisitions;  the  latter  connotes  a  single  acquisition  of 
some  larger  system. 

I  nteroperabi  I  ity  has  traditionally  been  considered  a  property  of  operational  systems. 
Efforts  to  achieve  interoperability  have  usually  focused  on  defining  communication 
protocols  and  interface  standards  and  verifying  (usually  through  testing)  conform¬ 
ance  to  them. 

Recent  work  at  the  Carnegie  Mellon®2  Software  Engineering  I  nstitute  (SEI )  has  led 
to  the  recognition  that  achieving  interoperability  actually  requires  an  understanding 
and  orchestration  of  activities  across  all  aspects  of  the  affected  systems.  A  useful 
approach  growing  from  that  work  is  to  consider  interoperability  in  terms  of  these  dis¬ 
tinct  aspects: 

•  operational— interoperability  among  entities  engaged  in  the  operation  ofsystems 
(As  previously  discussed,  this  aspect  is  the  focus  of  the  traditional  approach  to 
achieving  interoperability.) 

•  constructive— interoperability  among  entities  engaged  in  the  development  and 
mai  ntenance  of  systems 

•  programmatic— interoperability  among  entities  engaged  in  the  acquisition  man¬ 
agement  of  systems 

This  report  examines  programmatic  interoperability  and  discusses  its  relation  to  the 
other  aspects  of  interoperability.  The  discussion  is  focused  on  government  acquisi¬ 
tions,  but  many  of  the  principles  are  believed  to  apply  to  commercial  acquisitions  as 
well.  Wesuggest  that  achieving  interoperability  in  fielded  systems  requires  consider¬ 
ing  the  activities  in  each  of  those  aspects— as  well  as  their  interrelations. 

This  report  is  organized  as  follows: 

•  Section  2 

sets  the  context  through  an  overview  of  network-centric  principles  and  sys¬ 
tems  ofsystems  and  a  discussion  of  interoperability 

broadens  the  scope  of  interoperability  to  include  aspects  beyond  the  tradi¬ 
tional  context  of  operational  systems 


2.  Carnegie  Mellon  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 
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•  Section  3  examines  programmatic  interoperability  in  more  detail  through  discus¬ 
sion,  examples,  and  research  questions. 

•  Section  4  includes  a  discussion  of  the  orchestration  of  activities  and  decisions 
across  all  aspects  of  a  system  of  systems. 

•  Section  5  provides  a  summary  of  the  report. 
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2  Setting  the  Context 


2.1  DEFINING  NETWORK-CENTRIC  OPERATIONS  AND  SYSTEMS  OF  SYSTEMS 

The  terms  network-centric  operations  and  systems  of  systems  have  been  heavi  ly  used 
in  the  commercial  and  Department  of  Defense  (DoD)  domains.  Both  terms  express  a 
contrast  to  a  monolithic  system  that  is  managed  by  a  single  agency,  composed  of 
tightly  coupled  components,  and  designed  for  a  particular  set  of  tasks.  I  n  both 
domains,  the  hope  is  that  a  network-centric,  system-of-systems  approach  can  reduce 
the  time  needed  to  field  a  new  capability  and  increase  flexibility  in  dealing  with 
changes  in  requirements  or  technologies. 

Network-centric  operations  refers  to  a  collection  of  concepts  that  attempt  to  derive 
power  from  distributed,  interacting  entities  based  on  a  significantly  improved  access 
to  information.  These  principles  are  expected  to  provide  [Alberts  99] 

•  shared  awareness  through  the  fusion  of  data  from  many  different  types  of  sen¬ 
sors 

It  is  in  this  context  that  a  phrase  common  operational  picture  is  often  used. 

•  collaboration  among  virtual  organizations  designed  to  accomplish  a  specific  pur¬ 
pose 

•  execution  of  activities  by  other  entities,  often  distributed,  consistent  with  man¬ 
agement  intent,  giving  rise  to  the  expression  power  to  the  edge 

A  system  of  systems  can  be  viewed  as  a  way  to  implement  the  principles  of  network¬ 
centric  operations.  The  term  system  of  systems3  has  been  given  various  definitions; 
one  definition  that  we  use  reads  [Levine  03] 

system  of  systems:  a  set  or  arrangement  of  interdependent  systems  that  are 
related  or  connected  to  provide  a  given  capability 

One  set  of  characteristics  for  systems  of  systems,  provided  by  Maier,  includes  the  fol¬ 
lowing  [Maier  96] 

•  managerial  independence 

The  management  of  each  system  in  a  system  of  systems  is  independent  from  the 
management  of  the  other  systems. 

•  operational  independence 

Each  system  within  thesystem  of  systems  can  function  usefully  in  the  absence  of 
other  systems. 

•  evolutionary  character 

Each  system  within  the  system  of  systems  evolves  independently  of  other  sys¬ 
tems. 


3.  A  related  term  is  family  of  systems.  We  will  not  go  into  a  distinction  between  the  terms  system  of  systems  and 
family  of  systems.  Some  discussion  about  these  terms  appears  in  Requirements  Management  in  a  System-of- 
Systems  Context:  A  Workshop  [Meyers  06a]. 
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•  emergent  behavior 

The  behavior  of  the  system  of  systems  is  a  characteristic  of  the  interaction  of  the 
individual  systems  that  compose  the  system  of  systems;  it  is  not  embodied  in  any 
particular  system  and  is  a  consequence  of  the  interactions  that  take  place  among 
the  systems. 

The  combination  of  these  characteristics  means  that  the  policies,  practices,  proce¬ 
dures,  and  techniques  used  now  to  acquire,  develop,  field,  use,  and  sustain  stand¬ 
alone  systems— while  still  important— must  be  reinterpreted  and  perhaps  changed 
for  a  system-of-systems  context.* * 4  Furthermore,  new  policies,  practices,  procedures, 
and  techniques  may  need  to  be  formed  and  integrated  throughout  the  acquisition  life 
cydeto  meet  the  needs  of  acquisition  in  a  system-of-systems  context. 

2.2  DEFINING  INTEROPERABILITY 

We  also  recognize  that  the  current  approaches  to  interoperability  may  be  inefficient. 
Because  of  their  emphasis  on  principles  such  as  collaboration  and  characteristics  like 
emergence,  network-centric  operations  and  systems  of  systems  necessarily  rely  on 
interoperability.  Like  theterm  system  of  systems,  interoperability  has  many  defini¬ 
tions.  For  example,  this  I nstitute of  Electrical  and  Electronics  Engineers  (IEEE)  defi¬ 
nition  is  often  cited  [IEEE  00]: 

interoperability:  the  ability  of  two  or  moresystems  or  elements  to  exchange 
information  and  to  use  the  information  that  has  been  exchanged 

TheDoD  uses  multiple  definitions  of  interoperability,  all  of  which  are  based  to  some 
degree  on  definitions  developed  by  IEEE.  For  example,  one  definition  is[DoD  00] 

1.  Theability  of  systems,  units,  or  forces  to  provide  services  to  and  accept  ser¬ 
vices  from  other  systems,  units,  or  forces  and  to  use  the  services  so  exchanged 
to  enabl  e  them  to  operate  effecti  vely  together. 

2.  The  condition  achieved  among  communications-electronics  systems  or 
items  of  communications-electronics  equipment  when  information  or  services 
can  beexchanged  directly  and  satisfactorily  between  them  and/or  their  users. 

The  degree  of  interoperability  should  bedefined  when  referring  to  specific 
cases. 

Other  definitions  of  interoperability  from  the  I EEE,  the  DoD,  and  other  sources  are  in 
the  Appendix.  An  examination  of  the  I  EEE  and  DoD  definitions  presented  here  and 
those  in  the  Appendix  can  be  summarized  by  noting  thefollowing  point:  Theterm 
interoperability  has  been  traditionally  used  in  the  context  of  an  operational  system. 

We  believe,  however,  that  a  broader  approach  to  interoperability  is  needed.  We  base 
our  determination  on  the  view  that  interoperability  is  independent  of  a  domain  of 
application.  I  nteroperability  applies  to  the  acquisition  management  and  construction 
of  a  collection  of  systems  just  as  much  as  it  does  to  its  operation. 


4.  It  is  important  to  underscore  the  difference  between  the  terms  network-centric  operations  and  system  of  systems. 

The  former  emphasizes  concepts,  while  the  latter  emphasizes  a  realization  of  those  concepts. 
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In  keeping  with  that  view,  we  offer  thefollowing  definition  ([Levine  03],  [Morris  04]): 

interoperability:  theabilityofa  set  of  communicating  entities  to  (i) 
exchange  specified  information  and  (ii)  operate  on  that  information  according 
to  a  specified,  agreed-upon,  operational  semantics.5 

We  emphasize  the  domain-neutrality  and  primary  nature  of  this  definition.  Our  defi¬ 
nition  may  be  applied  to  any  context,  such  as  the  acquisition  management,  construc¬ 
tion,  or  operation  of  a  system  of  systems.  We  suggest  that  our  definition  is 
fundamental,  in  that  the  IEEE  and  DoD  definitions  given  earlier  can  be  derived  from 
it.6 

2.3  INFLUENCE  OF  INTEROPERABILITY  IN  ACQUISITION 

Given  that  interoperability  is  central  to  achieving  network-centric  concepts  in  sys¬ 
tems  of  systems  and  can  be  applied  in  many  contexts,  it  is  relevant  to  discuss  key 
influences  that  affect  the  acquisition  process.  Although  there  may  be  many  such  fac¬ 
tors,  our  focus  here  is  on  those  factors  that  closely  relate  to  the  considerations  regard¬ 
ing  the  basic  elements  of  interoperability.  Thus,  thefollowing  discussion  is  couched  at 
a  higher  level  to  emphasize  principles. 

2.3.1  Scope  of  Interaction 

I  nteroperability  in  the  acquisition  process  is  influenced  by  the  scope  of  interaction 
among  organizations  that  participate  in  the  process.  I  n  support  of  this  claim,  we  con¬ 
sider  the  basic  situations  shown  in  Figure  1. 


(a)  Within  the 
same 

organization 


(b)  Between  different 
organizations, 
known  to  each  other 


(c)  Between  different 
organizations, 
possibly  unknown 


Note:  Different  acquisition  functions  are  denoted  by  the  symbols  O  •  • 


Figure  1:  Models  of  the  Scope  of  Interaction 


5.  Operational  semantics  refers,  loosely,  to  the  semantics  of  operations  that  are  performed  by  an  abstract  machine 
capable  of  executing  a  specification.  Operations  may  be  defined  in  terms  of  pre-  and  post-conditions  whose  ap¬ 
plication  may  result  in  a  state  change.  The  meaning  of  the  (abstract)  specification,  then,  is  defined  in  terms  of  the 
operations  that  may  be  performed. 

6.  Quality  characteristics  such  as  interoperability  are  sometimes  defined  in  measurable  terms.  In  this  approach,  our 
definition  of  interoperability  would  begin  with  the  phrase  “The  degree  to  which.”  Although  such  an  approach  can 
be  taken  and  has  interest  in  its  own  right,  we  shall  not  pursue  that  path  here.  The  idea  of  measuring  interoperability 
does,  however,  raise  the  interesting  issue  of  determining  the  relevant  metrics. 
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The  different  cases  depicted  by  the  models  in  Figure  1  are  described  as  follows: 

•  Case  (a)  represents  interoperability  within  a  particular  organization.  In  general, 
this  is  the  easiest  case  because  a  single  organization  is  likely  to  have  common 
practices,  culture,  and  decision-making  processes. 

•  Case  (b)  represents  interoperability  between  different,  but  known,  organiza¬ 
tions.7  Dealing  with  different  organizations  adds  consideration  for  organizational 
policies  and  practices  that  might  be  in  conflict.  It  is  assumed  in  this  model  that 
the  set  of  communicating  entities  is  known  and  relatively  stable  over  time. 

•  Case  (c)  is  fundamentally  different  from  (b)  in  that  the  identity  of  the  other  orga¬ 
nizations  may  not  be  known.  This  case  is  analogous  to  an  organization  present¬ 
ing  information  about  risk  management  to  others  that  may  need  such 
information— independent  of  any  prior  agreement  about  which  organizations 
should  be  given  that  information. 

The  three  cases  can  be  seen  as  depicting  two  situations  that  are  quite  different.  The 
first  two  cases  are  typical  of  a  bounded  environment,  in  that  the  communicating  enti¬ 
ties  and  their  number  are  known  (and  traditionally  they  are  relatively  stable  over 
time).  The  last  case  is  characteristic  of  an  unbounded  environment  in  which  the  iden¬ 
tity  and  number  of  communicating  entities  may  not  be  known.  That  situation,  an 
unbounded  environment,  is  often  found  in  network-centric  operations  and  systems  of 
systems.8 

There  are  additional  concerns  that  are  related  to  the  question  of  scope.  For  example, 
each  of  the  three  cases  presents  different  governance  frameworks.  As  organizations 
interact,  the  consequences  of  those  different  governance  frameworks  may  lead  to  con¬ 
flicts  among  the  entities  that  are  I  ess  likely  when  one  considers  a  single  organization. 
The  question  of  governance  is  but  one  example;  we  would  suggest  any  process  per¬ 
formed,  such  as  requirements  management  or  schedule  management,  may  be  a 
source  of  contention. 

2.3.2  Nature  of  Agreements 

I  nteroperability  in  the  acquisition  process  is  also  influenced  by  the  nature  of  agree¬ 
ments  among  organizations  that  participate  in  the  process.  Various  types  of  agree¬ 
ments  can  be  considered  as  part  of  achieving  interoperability: 

•  public  law 

•  contractual  relationships 

•  memoranda  of  understanding  (explicit,  yet  informal,  agreements) 


7.  There  are  gradations  possible  for  this  case.  For  example,  one  could  distinguish  between  organizations  that  are 
different  but  somehow  closely  related  (within  the  same  agency)  and  organizations  that  are  unrelated  (such  as  an 
acquisition  organization  and  a  contractor). 

8.  Our  intent  here  is  not  to  go  into  the  details  of  the  unbounded  case.  However,  consider  an  environment  in  which 
information  is  available  to  others,  although  the  identity  of  the  consumers  of  information  may  not  be  known.  Some 
organization  may  take  information  from  this  environment  and,  if  it  chooses,  enter  into  an  agreement  with  the  or¬ 
ganization  that  placed  the  information  there.  This  is  still  an  unbounded  environment  in  that  others,  who  may  not 
be  known,  can  gain  information,  and  then,  if  necessary,  engage  in  binding  agreements  with  providers  of  informa¬ 
tion.  Of  course,  the  nature  of  agreements  need  not  involve  only  pair-wise  interactions. 
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•  implicit  agreements  (For  example,  if  two  organizations  agree  to  conform  to  the 
same  standard,  they  have  in  effect  entered  into  an  agreement.) 

I  n  some  sense,  any  type  of  agreement  can  be  regarded  as  an  influence  relation.  The 
nature  of  the  i  nfl  uence  is  often  connected  to  the  expected  behavior  of  the  entiti  es  that 
engage  in  an  agreement.  For  example,  a  contract  specifies  expected  behavior  as 
agreed  to  by  the  contracting  agent  and  the  contractor.  I  n  this  sense,  a  contract  repre¬ 
sents  a  strong  form  of  i  nfl  uence. 

Different  types  of  agreements  are  related  to  the  character  of  an  organization  entering 
into  an  agreement.  The  character  is  determined  in  part  by  the  environment  in  which 
the  agreement  takes  place.  When  a  government  agency  enters  into  an  agreement,  for 
example,  that  agreement  is  determined  in  part  by  the  regulations  that  govern  the 
behavior  of  the  agency.  Such  regulations  are  different  when  an  agreement  is  under¬ 
taken  by  two  commercial  firms.  The  subject  of  organizations  and  their  agreements  is 
discussed  in  System-of -Systems  N avi gator:  An  Approach  for  M  anagi  ng  System-of-Sys- 
tems  I nteroperability  [Brownsword  06], 

2.3.3  Shared  Information 

Fundamental  to  any  discussion  of  interoperability  is  the  information  that  is  shared. 
Two  significant  considerations  are  what  information  needs  to  be  shared  and  who 
decides  that  information.  The  unbounded  environment,  Case  (c)  in  Section  2.3.1,  pre¬ 
sents  problems  in  the  implications  for  sharing  information  and  the  issue  of  whether 
the  necessary  information  can  be  determined  at  runtime.  Further,  if  that  determina¬ 
tion  can  be  made  at  runtime,  the  unbounded  environment  is  also  dynamic,  making  it 
considerably  more  challenging— and  interesting— than  a  static,  bounded  one. 

2.4  ASPECTS  OF  INTEROPERABILITY 

Our  definition  of  interoperability  recognizes  that  it  is  a  general  property  of  some  col¬ 
lection  of  entities  and  is  applicableto  different  functional  domains.  I  n  particular,  the 
acquisition  management,  system  construction,  and  system  operation  functional 
domains  are  important  for  a  discussion  of  acquisition. 

The  functions  in  those  domains  are  performed  by  organizations.  I  n  Figure  2,  we  show 
the  nature  of  the  relationship  between  types  of  functions  (denoted  as  solid,  shaded, 
and  open  circles)  and  the  types  of  organizations  that  perform  them  (depicted  as  solid, 
shaded,  and  open  squares). 
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I  n  Figure  2,  notice  that  the  same  type  of  function  can  be  performed  by  different  types 
of  organizations  and  that  the  same  organization  can  perform  different  types  of  func¬ 
tions. 


Functions 


Organizations 


Figure  2:  Mapping  of  Functions  to  Organizations 


As  noted  earlier,  interoperability  has  traditionally  been  considered  a  property  of  the 
system  operation  domain  only.  The  SEI  has  developed  a  model  showing  how  interop¬ 
erability  among  those  aspects  works  (see  Figure  3).  The  system-of-systems  interoper¬ 
ability  (SOSI )  model  arose  from  an  earlier  SEI  I  ndependent  Research  and 
Development  effort  whose  details  are  described  in  two  previous  reports  ([Levine  03], 
[Morris  04]). 


Program-1  Program-2 


Figure  3:  SOSI  Model 


Figure  3  simply  shows  two  acquisitions,  denoted  Program-1  and  Program-2.  The  func¬ 
tions  performed  within  each  program  are  identified  as  well  as  the  various  types  of 
interoperability  relations  between  them.  While  showing  only  pair-wise  interactions, 
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Figure  3  introduces  concepts  that  are  easily  extensibleto  a  larger  number  of  organi¬ 
zations.  Thus,  it  includes  the  terms 

•  programmati  c  i  nteroperabi  I  ity 

This  concept  refers  to  interoperability  in  the  context  of  acquisition  management; 
it  is  our  focus  and  will  be  discussed  further. 

•  constructive  interoperability 

This  concept  refers  to  interoperability  in  the  context  of  the  construction  of  sys¬ 
tems. 

•  operational  interoperability 

This  concept  refers  to  interoperability  in  the  operational  context.  The  traditional 
view  is  that  interoperability  is  viewed  as  operational  interoperability. 

There  are  two  dimensions  of  interaction  shown  in  Figure  3.  Along  the  vertical  dimen¬ 
sion  there  is,  as  one  would  expect,  interoperability  among  constituents  in  the  context 
of  a  particular  acquisition  program.  I  n  general,  this  is  the  easier  case,  since 

•  The  interaction  between  the  functions  of  acquisition  management  and  system 
construction  is  governed  by  a  contract,  which  is  a  formal  agreement  having  a 
strong  intent.  The  interaction  may  also  include  subcontractual  relations  (e.g.,  a 
pri  me  to  a  subcontractor).  1 1  may  also  i  ncl  ude  other  contractual  agreements,  such 
as  with  an  organization  that  performs  independent  verification  of  a  system. 
Thus,  in  general,  the  governance  of  the  relations  among  the  constituents  is  more 
formal  and  stronger  in  intent. 

•  The  constituents  engaged  in  the  acquisition  of  a  system  have  a  vested  interest  in 
the  acquisition  process  and  may  partici pate toa  significant  degree.  For  example, 
it  is  often  the  casethat  a  user  (representing  the  operational  community)  is 
involved  in  acquisition  management  decisions.  Organizations  typically  communi¬ 
cate  more  with  each  other,  through,  for  example,  the  use  of  integrated  product 
teams. 

The  vertical,  or  program-centric,  perspective  shown  in  Figure  3  has  strengths  and 
weaknesses.  Its  strengths  rest  with  its  focus  on  a  particular  system.  Its  weaknesses 
stem  from  a  failure  to  consider  a  larger  acquisition  perspective  that  limits  effective¬ 
ness  beyond  the  program-centric  perspective  and  leads  to  the  well-known  "stovepipe" 
behavior.  The  second  dimension  of  interoperability  shown  in  Figure  3  takes  place 
along  the  horizontal  perspective.  This  view  focuses  on  interoperability  among  the 
functions  performed  by  constituents  that  are  engaged  in  different  acquisitions. 

This  second  dimension  represents  the  more  difficult  case,  as  the  governance  process 
of  each  organization  is  more  tenable;  for  example,  the  relation  between  different 
acquisition  management  organizations  may  be  manifest  by  verbal  agreements  rather 
than  a  more  formal  type  of  agreement.  There  is  also  little  or  no  explicit  relation 
between  organizations  engaged  in  the  construction  of  different  systems.9 

9.  However,  there  may  be  implicit  relations  among  organizations  producing  different  systems.  A  simple  example  is 
that  each  organization  may  adhere  to  the  same  standard.  It  is  through  commonality  of  standards  that  one  might 
expect  interoperability  among  systems  to  be  achieved.  In  this  sense,  a  standard  serves  as  the  bridge  between 
systems,  even  in  the  development  context. 
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Taken  together,  the  interactions  shown  in  Figure  3  represent  various  aspects  of 
interoperability  that  need  to  be  understood  and— to  the  extent  practicable— managed. 
These  aspects  lieboth  within  and  between  organizations  that  participate  in  the  acqui¬ 
sition  process.  Furthermore,  it  is  the  interaction  among  the  types  of  interoperability 
that  presents  challenges  to  the  success  of  acquisition  in  the  context  of  a  system  of  sys¬ 
tems. 

The  diagram  in  Figure  3  appears  quite  simple,  and  there  is  sometimes  a  tendency  to 
interpret  it  in  an  equally  simple  manner.  For  example,  it  would  be  quite  easy  to 
assume  that  programmatic  interoperability  represents  interoperability  between  only 
acquisition  management  organizations.  Such  an  interpretation  is  overly  simplistic 
and,  at  best,  ambiguous. 

2.5  PROGRAMMATIC  INTEROPERABILITY 

Our  approach  to  developing  a  definition  of  programmatic  interoperability10  is  to 
amend  the  definition  of  interoperability  from  page  5,  as  follows: 

programmatic  interoperability:  Theability  of  a  set  of  communi  cati  ng 
entities  engaged  in  acquisition  management  activities  to  (i)  exchange  spec¬ 
ified  acquisition  management  information  and  (ii)  operate  on  that  acquisi¬ 
tion  management  information  according  to  a  specified,  agreed-upon, 
operational  semantics. 

The  exchanged  information  has  syntactic  (form)  and  semantic  (meaning)  content. 
Syntactic  matters  are  easier  to  resolve  than  semantic  issues.  Many  concerns  can  arise 
out  of  the  interpretation  of  the  semantics,  however.  It  is  also  necessary  to  understand 
the  relation  between  the  two  elements.  For  example,  a  "high  risk”  (semantic)  might 
be  defi  ned  as  havi  ng  a  val  ue  greater  than  0.8  (syntacti  c). 

Consideration  of  behaviors  is  also  relevant.  Some  of  these  behaviors  relate  to  commu¬ 
nication  aspects.  For  example,  it  is  reasonable  to  assume  that  if  an  entity  gains  some 
new  information,  that  entity  needs  to  distribute  the  information  to  others.  The  infor¬ 
mation  passed  on,  the  other  entities  that  need  it,  and  the  requirements  for  its  distri¬ 
bution  would  haveto  be  worked  out.  This  type  of  communication  ensures  that  entities 
share  information  deemed  relevant  with  others  that  need  it. 

The  sharing  of  information  by  some  entity  emphasizes  the  behavioral  aspects  of  that 
particular  entity.  From  this,  it  is  important  to  consider  the  collective  behavior  that 
multiple  entities  perform  in  their  approach  to  programmatic  interoperability.  For 
example,  sharing  of  risk  information  is  the  first  step;  what  must  follow  is  the  collec¬ 
tive  behavior  to  deal  with  that  risk  information. 

Toengagein  collective  behavior,  entities  must  also  have  some  knowledge  of  the  qual¬ 
ity  of  that  information.  Sharing  high-quality  information  leads  to  trust  among  com¬ 
municating  entities.  Flowever,  shared  information  of  low  quality  or  highly  variable 
quality  can  lessen  trust,  resulting  in  behavior  that  is  less  likely  to  have  positive 
results. 

10.  In  the  following  we  refer  explicitly  to  acquisition  management,  as  opposed  to  simply  management.  Management 
operations  are  performed  in  all  contexts,  such  as  the  construction  or  operation  of  a  system.  Correspondingly,  a 
term  such  as  management  interoperability  would  be  ambiguous  without  the  context  in  which  that  management 
occurs. 
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Consider  an  example  from  risk  management.  Most  discussions  of  risk  management 
include  some  discussion  of  processes  related  to  risk  identification.  There  are  many 
methods  (and  tools)  to  identify  risks,  such  as  interviews,  brainstorming,  question¬ 
naires,  and  analysis  of  risks  on  similar  projects.  Each  of  these  methods  might  apply 
different  resources  and  provide  results  of  differing  quality.  Despite  all  of  that  variety, 
some  knowledge  of  the  quality  of  information  about  risks  is  needed  if  the  sharing  of 
that  information  is  to  foster  collective  behavior. 

But  the  information  exchanged  and  the  quality  of  that  information  are  separate  con¬ 
siderations.  The  quality  of  information  in  a  standard  and  the  means  by  which  that 
information  is  established,  for  instance,  are  determined  through  the  implementation 
of  practices  by  an  organization.  By  implication,  organizational  practices  relevant  to 
some  programmatic  function  can  directly  impact  the  quality  of  the  information  gath¬ 
ered  and  exchanged.11 

The  preceding  discussion  has  illustrated  several  aspects  of  programmatic  interopera¬ 
bility,  including  sharing  of  information  and  engaging  in  collective  behavior  in  light  of 
concerns  regarding  syntax,  semantics,  and  qualities  of  information.  The  activities, 
and  their  characteristics,  are  relevant  when  one  seeks  to  face  the  challenges  of  viable 
acquisition  in  a  system-of-systems  context  successfully. 


1 1 .  For  processes,  compliance  to  some  model,  such  as  the  CMMI®  framework,  alone  does  not  always  produce  high- 
quality  results  in  an  implementation.  In  short,  compliance  is  necessary,  but  it  is  not  sufficient.  The  SEI  report  Pro¬ 
cess  Considerations  for  Interoperable  Acquisition  examines  the  role  of  process  in  interoperable  acquisition  [Gar¬ 
cia  06].  (CMMI  is  registered  in  the  U.  S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University.) 
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3  The  Programmatic  Aspect  of  Interoperability 


I  n  this  section,  we  explore  the  main  concepts  of  programmatic  interoperability,  pro¬ 
vide  some  examples  of  problems  and  successes  in  programmatic  interoperability,  and 
raise  some  questions  for  research.  Programmatic  interoperability  permits  acquisition 
entities  to  make  better  decisions  with  regard  to  the  acquisition  management  aspects 
of  a  system-of-systems  environment.  T o  meet  the  needs  of  a  system  of  systems,  it  is 
important  to  stress  the  perspective  of  a  collection  of  entities  in  the  processes  that 
influence  the  product(s)  delivered  to  the  end  user. 

3.1  CONCEPTS 

A  view  of  programmatic  interoperability  that  builds  from  our  general  definition  of 
programmatic  interoperability  on  page  10  and  emphasizes  acquisition  is  as  follows: 

programmatic  interoperability:  The  ability  of  a  set  of  communicating 
entities  to  achia/ea  shared  understanding  with  respect  to  acquisition  man¬ 
agement  functions  to  allow  them  to  engage  in  effective  collective  behavior. 

This  definition  naturally  leads  to  several  questions,  namely: 

•  What  are  the  communicating  entities  that  participate  in  acquisition  manage¬ 
ment  activities? 

•  What  acquisition  management  information  needs  to  be  shared  to  achieve  pro¬ 
grammatic  interoperability? 

•  How  is  the  quality  of  the  relevant  information  determined? 

•  What  behaviors  allow  effective  collective  behavior?  H  ow  is  effectiveness  of  behav¬ 
ior  determined? 

I  n  the  foil  owing  sections,  we  briefly  comment  on  these  questions  through  viewing 
three  concepts  of  programmatic  interoperability:  communicating  entities,  sharing  of 
acquisition  management  information,  and  operations  on  the  shared  information. 

3.1 .1  Entities  and  Their  Means  of  Communicating 

Froma  DoD  acquisition  perspective,  we  can  assume  that  the  entities  most  relevant  to 
programmatic  interests  are  the  acquisition  management  office  (typically  a  PMO)  and 
program  executive  office  (PEO).  Other  relevant  entities  may  be  a  milestone  decision 
agent  (MDA)  or  a  resource  allocation  representative  such  as  the  well-known  Program, 
Planning,  Budgeting,  and  Execution  System  (PPBES).12  Overall,  the  range  of  com¬ 
municating  entities  could  include 

•  PM  Os,  PE  Os,  MDAs,  and  service  acquisition  authorities 

•  Federal  agencies,  such  as  the  Department  of  Homeland  Security  (DHS) 

•  Congressional  oversight  committees 

•  state  and  local  governments 

•  international  partners 


12.  Some  background  on  the  PPBES  system  can  be  found  at  on  the  organization’s  Web  site  [PPBES  03]. 
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I  n  addition  to  government  organizations,  other  types  of  entities  may  participate  in 
the  acquisition  management  process,  such  as 

•  contractors  of  the  systems  that  are  i  ntended  to  i  nteroperate 

•  representatives  from  the  user  community 

•  managers  of  suppliers  of  commercial  products  that  are  used  in  thesystems13 

Two  other  factors  are  as  important  as  the  identification  of  entities:  (1)  the  means  by 
which  entities  communicate  and  (2)  the  protocol  employed  (where  a  protocol  defines 
the  syntax  and  semantics  of  a  communication  process).  When  considering  a  protocol, 
entities  also  must  address  concerns  about  when  and  how  communication  takes  place. 

3.1.2  Acquisition  Management  Information 

By  looking  at  the  acquisition  management  information,  we  are  moving  from  a  focus 
on  who  communicates  and  how  they  communicate  to  what  is  communicated.  We  are 
interested  herein  the  information  that  needs  to  be  visible  in  order  to  achieve  interop¬ 
erability  in  the  programmatic  context.  Certainly,  information  associated  with  sched¬ 
ule  (especially  schedule  variance)  falls  into  this  category.  I  nformation  related  to 
products  (both  function  and  quality)  is  a  prime  candidate,  too,  as  is  information 
related  to  risk  management.  Other  types  of  information  may  be  necessary  as  well, 
notably  drivers  from  the  operational  community. 

Those  elements  may  be  obvious  types,  but  other  forms  of  information  are  less  well 
recognized.  Consider  cost,  for  instance:  What  information  regarding  cost  needs  to  be 
shared,  and  why  does  it  need  to  be  shared?  Questions  surrounding  the  sharing  of  cost 
information  illustrate  a  typical  difficulty  in  achieving  interoperability  in  an  acquisi¬ 
tion  management  context.  Programs  are  naturally  protective  of  cost  information. 
However,  the  ability  to  reprogram  funding  among  programs  may  justify  sharing  cost 
information.14  Similarly,  one  might  expect  to  gain  insight  into  risks  affecting  sched¬ 
ule.  However,  which  risk,  what  level  of  detail  about  the  risk,  and  how  the  quality  of 
information  about  the  risk  is  to  be  assessed  need  to  be  identified.  I  ndeed,  for  all  types 
of  information,  entities  need  to  specify  what  details  (and  at  what  level  of  specifica¬ 
tion)  are  relevant  to  share  and  be  ableto  assess  the  quality  of  information  shared. 


13.  The  list  of  other  entities  can  be  extended  to  include  various  types  of  organizations  involved  in  short-term,  limited 
interactions — a  view  that  brings  one  close  to  virtual  organizations  and  their  collaboration,  a  tenet  of 
network-centric  operations. 

14.  Reprogramming  thresholds  for  costs  among  programs  are  specified  in  statute.  Overall,  we  might  ask:  Do  statutes 
and  DoD  policies  impose  a  barrier  on  achieving  programmatic  interoperability?  If  they  do,  what  needs  to  be 
changed?  The  implications  of  statute  (in  particular,  Title  1 0)  for  acquisition  in  a  system-of-systems  context  is  under 
examination  by  the  authors  of  this  technical  note  and  will  appear  in  a  forthcoming  report. 
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3.1.3  Operations 

An  entity  performs  behaviors,  and  a  behavior  may  be  viewed  as  an  operation.  Of  rele¬ 
vance  to  the  programmatic  aspect  is  that  these  operations  are  performed  on  acquisi¬ 
tion  management  information.15  We  consider  a  process  to  be  an  encapsulation  of 
operations.  Many  types  of  processes  are  relevant  to  acquisition  management,  such  as 
those  dealing  with  acquisition  strategy  management,  cost  management,  contract 
management,  schedule  management,  or  risk  management.16  Details  of  specific  pro¬ 
cesses  are  not  relevant  to  this  report. 

There  are  problematic  issues  with  information  about  process,  particularly  with 
respect  to  i  nteroperabi  I  ity  among  processes.  Some  argue  that  the  output  from  a  pro¬ 
cess  is  relevant  and  that  how  the  output  is  produced  is  not  important.  A  counter  to 
this  argument  is  that  sharing  details  of  how  a  process  is  performed  can  be  useful,  if 
only  as  a  learning  opportunity.  Further,  those  details  could  be  used  to  judge  the  qual¬ 
ity  of  work  performed.  Whether  they  deem  the  output  or  the  detail  important,  entities 
need  to  establish  a  frame  of  reference  to  effectively  share  any  process-derived  infor¬ 
mation. 

3.1 .4  Summary  of  Perspectives  on  Programmatic  Interoperability 

Programmatic  interoperability,  as  we've  seen,  can  be  considered  from  the  perspec¬ 
tives  of  communicating  entities,  the  information  they  share,  and  the  operations  that 
are  performed  on  that  information.  I  n  essence,  these  three  perspectives  represent  ele¬ 
ments  in  an  acquisition  in  a  system-of-systems  context,  a  situation  that  we  frame  as 
interoperable  acquisition.  The  SE I  has  reported  on  research  into  some  key  areas  for 
interoperable  acquisition:  challenges  facing  the  entities  involved  [Smith  06],  risk 
management  [Meyers  06b],  and  schedule  [Meyers  06c], 


15.  The  operations  (behaviors)  of  each  entity  are  important:  even  more  significant  is  collective  behavior. 

16.  The  SEI  work  in  the  area  of  processes  for  acquisition  includes  the  CMMI  framework  for  process  and  product  im¬ 
provement  [Chrissis  03]  and  its  extension  for  acquisition  organizations  [Dodson  06].  It  is  also  expected  that  the 
SEI  will  release  the  CMMI  for  acquisition  (denoted  CMMI-ACQ)  in  the  near  future. 
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3.2  PROGRAMMATIC  INTEROPERABILITY  EXAMPLES 


These  examples  are  based  on  our  interactions  with  customers  and  include  both  prob¬ 
lems  and  successes. 

Table  1:  Examples  of  Programmatic  Interoperability 


Context 

Problem 

Resolution  or  Outcome 

Reuse  in  an 
integration  context 

Development  of  a  large  system  emphasized 
the  reuse  of  products  created  by  other  acqui¬ 
sition  efforts.  However,  the  integration  agent 
did  not  specify  any  entrance  criteria  for  can¬ 
didate  reusable  products.  The  products  were 
selected  without  regard  to  maturity  or  quality. 

Numerous  problems  plagued  the  integration 
effort.  One  unresolved  issue  was  the  ques¬ 
tion  of  who  should  pay  to  make  changes  to 
the  reused  products. 

Synchronization 
through  a  contract 
specifying  the  use  of 
standards 

In  an  acquisition  effort  where  multiple  sys¬ 
tems  were  expected  to  interoperate,  some 
synchronization  among  the  programmatic 
entities  was  needed.  One  implicit  approach 
to  achieving  the  desired  synchronization  was 
through  the  contract  that  mandated  compli¬ 
ance  with  various  standards. 

Unfortunately,  different  implementations  of 
the  same  standard  caused  problems  during 
integration.  Contracts  are  typically  structured 
from  the  perspective  of  a  particular  system, 
rather  than  the  collection  of  systems. 

Integration  of 
requirements 

In  an  acquisition  effort  where  multiple  sys¬ 
tems  were  expected  to  interoperate,  require¬ 
ments  were  placed  against  the  individual 
systems  and  their  integration.  But  little  atten¬ 
tion  was  paid  to  conflicts  among  require¬ 
ments.  Furthermore,  there  was  a  conflict 
between  the  top-down  approach  specified  in 
DoD  policies  and  the  actual,  bottom-up  pro¬ 
cess  employed  to  achieve  interoperability 
between  operational  systems. 

The  lack  of  any  acquisition  management 
process  that  addressed  the  full  scope  of 
requirements  management  (i.e. ,  require¬ 
ments  at  the  system-of-systems  level)  was 
an  ongoing  source  of  difficulty.  (Require¬ 
ments  management  conflicts  in  a  system  of 
systems  are  discussed  in  a  previous  report 
[Meyers  06a].) 

Schedule  problems 
in  integration 

In  a  simulation  for  a  large  collection  of  sys¬ 
tems,  insufficient  attention  was  paid  to  the 
coordination  and  acquisition  management  of 
the  overall  schedule.  Thus,  it  was  not  sur¬ 
prising  when  the  simulation  was  not  deliv¬ 
ered  on  time. 

There  was  a  delay  in  meeting  schedule. 

Also,  the  rush  to  produce  one  system  less¬ 
ened  its  quality  and  caused  problems  in  inte¬ 
gration.  It  was  not  simply  the  lack  of  an  agent 
responsible  for  coordination  of  schedules;  of 
greater  importance  was  the  lack  of  sharing  of 
information. 

Joint  award  fee 
board3 

Two  PMOs  used  the  same  prime  contractor 
for  their  respective  systems.  The  systems 
being  produced  had  a  number  of  important 
interoperability  requirements.  The  PMOs 
decided  to  conduct  a  joint  award  fee  board. 

Rather  than  satisfying  an  individual  PMO, 
the  award  fee  board  changed  its  focus  to 
stress  interoperability  between  systems.  The 
contractor  preferred  this  approach;  a 
decrease  in  interoperability  problems 
resulted. 

System  engineering 
resourcing  oversight 

A  number  of  large  systems  were  being 
acquired  separately.  However,  it  did  not  take 
long  to  realize  that  there  had  been  no  alloca¬ 
tion  of  resources  (funding  and  staff)  in  order 
to  address  issues  related  to  system  engi¬ 
neering  of  the  collection  of  systems. 

The  individual  programs  could  not  work  out 
the  resourcing  oversight,  because  they 
focused  on  their  own  systems.  Failure  to  rec¬ 
ognize  programmatic  concerns  related  to 
system  engineering  caused  difficulties 
throughout  the  integration. 

a.  Joint  award  fee  boards  have  many  interesting  aspects,  including  the  business  strategies  of  the  organizations  in¬ 
volved  in  constructing  a  system.  For  example,  a  contractor  may  choose  to  sacrifice  part  of  an  incentive  fee  award 
to  satisfy  longer  term  business  goals.  Or,  intellectual  property  concerns  about  sharing  information  among  devel¬ 
opment  organizations  may  warrant  taking  such  a  position.  (One  counter  to  this  action  is  the  use  of  past  perfor¬ 
mance  evaluations  by  government,  but  its  use  may  be  difficult.)  The  preceding  examples  underscore  that 
acquisition  in  a  system-of-systems  context  and  its  inherent  interoperability  considerations  can  be  significantly  dif¬ 
ferent  from  the  acquisition  of  a  particular  system. 
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In  each  case  detailed  inTabl  el,  there  are  implications  for  how  the  management  of  an 
acquisition  involving  a  collection  of  systems  can  be  approached.  I  n  the  reuse  scenario, 
for  instance,  the  absence  of  criteria  for  selecting  products  proved  detrimental;  in  the 
example  of  a  contract  used  to  synchronize  integration  activities,  the  repeated  use  of 
the  same  standard  caused  problems  due  to  differing  implementations;  failure  to  rec¬ 
oncile  requirement  conflicts,  coordinate  schedules,  or  provide  adequate  resources  for 
system-of-systems  engineering  negatively  affected  other  efforts.  One  approach  did 
have  positive  results:  the  use  of  a  joint  award  fee  board  provided  incentives  to  focus 
on  the  interoperability  between  systems. 

Problems  resulted  in  five  of  the  six  examples  described  in  Table  1.  One  inference  from 
the  outcomes  is  that  a  traditional  approach  to  acquisition  is  not  sufficient  for  a  sys- 
tem-of-systems  environment.  Each  outcome,  the  problems  as  well  as  the  success,  sup¬ 
ports  our  contention  that  operational  interoperability  is  more  likely  to  be  achieved  if 
consideration  of  programmatic  (and  constructive)  interoperability  is  addressed 
throughout  the  acquisition  process. 

3.3  PROGRAMMATIC  INTEROPERABILITY  RESEARCH  ISSUES 
Many  issues  surround  programmatic  interoperability,  including 

How  does  one  identify  the  communicating  entities  that  participate  in  programmatic 
interoperability  and  their  degree  of  boundedness? 

Clearly,  it  is  necessary  to  identify  the  entities  that  need  to  communicate  in  order  to 
achieve  programmatic  interoperability.  An  interesting  aspect  of  this  question  is  the 
bounded  or  unbounded  nature  of  the  interactions.  We  see  two  relevant  perspectives, 
illustrated  in  Figure  1  on  page  5  where: 

1.  the  entities  and  their  number  are  known  and  relatively  stable  over  time  (the 
bounded  case) 

2.  the  entities  and  their  number  are  not  known  (the  unbounded  case) 

These  perspectives  represent  limits  in  the  temporal  interactions  among  the  inter¬ 
ested  entities.  It  is  one  thing  to  share  information  with  a  relatively  small  number  of 
entities,  but  it  is  quite  something  else  to  make  information  avail  able  to  anyone. 
Notice  that  the  unbounded  case  has  a  close  parallel  to  discussions  about  network-cen¬ 
tric  operations. 

What  information  must  be  shared  to  achieve  programmatic  interoperability? 

Describing  the  communicating  entities,  acquisition  management  information,  and 
operations  on  that  information  is  important,  as  we  mentioned  in  Section  3.1.  Of  even 
greater  significance  is  to  identify  the  specific  entities,  acquisition  management  infor¬ 
mation,  and  operations.  Consider  the  case  of  sharing  information  about  schedule  in 
the  context  of  risk  management.  Should  an  organization  expose  the  inability  to  meet 
a  scheduled  milestone?  We  say  yes.  But  should  the  organization  also  expose  the  risks 
associated  with  failing  to  meet  that  milestone?  This  question  is  problematic.  An  orga¬ 
nization  might  statea  risk  inthisway:  'The integration  facility  is  not  on  scheduledue 
to  a  delay  in  implementing  air  conditioning  in  the  facility;  there  is  a  risk  tothesched- 
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ulefor  the  readiness  of  the  facility."  Is  it  really  necessary  to  expose  that  there  is  a  risk 
to  the  completion  of  the  facility  due  to  an  air  conditioning  problem?  Many  organiza¬ 
tions  would  argue  that  the  important  point  is  that  thefacility  is  "not  on  schedule."17 

How  does  one  assess  the  quality  of  information  shared? 

Entities  need  to  know  the  quality  of  shared  information  to  make  decisions  that  will 
affect  their  collective  behavior.  Typically,  pieces  of  information  are  of  varying  quality. 
The  range  of  information  quality  could  be  reflected  in  decisions  reached  on  that  infor¬ 
mation.  How  can  an  organization  know  whether  the  information  provided  is  of  suffi¬ 
cient  quality  that  the  collective  decisions  reached  and  collective  behavior  performed 
are  appropriate? 

What  are  the  implications  of  programmatic  interoperability  for  process? 

The  role  of  process  in  acquisition  is  well  known;  it  has  been  incorporated,  for  example, 
into  the  CM  Ml  framework  for  acquisition  [Dodson  06],  When  we  add  a  consideration 
of  interoperability  to  acquisition,  two  issues  emerge: 

1.  How  should  existing  processes  be  modified  to  account  for  interoperability  when 
the  scope  of  an  acquisition  is  larger  than  an  individual  program? 

2.  What  additional  processes  are  necessary  to  address  interoperability  among 
acquisition  management  organizations? 

Notice  that  each  of  the  examples  given  in  Section  3.2  has  implications  for  acquisition 
processes.  We  expect  that  questions  related  to  process  are  important,  because  a  pro¬ 
cess  perspective  is  expected  to  be  an  important  component  of  programmatic  interoper¬ 
ability.18 

What  collaborative  behaviors  support  successful  programmatic  interoperability? 

A  key  to  achieving  programmatic  interoperability  is  that  the  relevant  entities  engage 
in  collective  behavior  beyond  sharing  information.  I  n  particular,  for  a  function  such 
as  risk  management,  it  is  necessary  to  identify  behaviors  for  each  entity  as  well  as 
collaborative  behaviors  for  all  relevant  entities.  A  start  to  identify  collaborative 
behaviors  has  been  discussed  for  schedule  management  in  ScheduleConsiderations 
for  I  interoperable  Management  [M  eyers  06c], 

How  much  automated  support  can  be  provided  to  programmatic  interoperability? 

We  envision  acquisition  being  conducted  with  greater  support  from  automated  sys¬ 
tems.  We  believe  more  automation  is  necessary  to  meet  the  increased  demand  for 
acquisition  management  information  sharing.  If  one  accepts  this  premise,  where  can 
such  support  be  brought  to  bear?  For  example,  if  there  is  a  change  to  some  attribute 
of  a  schedule  for  some  system  (e.g.,  a  modification  to  a  milestone  or  the  knowledge  of 
its  schedule  variance),  how  can  that  information  be  efficiently  distributed?  How  can 
such  information  be  further  processed  by  receiving  entities  with  automated  support? 


1 7.  An  example  like  this  one  suggests  that  how  much  risk  information  an  organization  is  willing  to  share  in  general 
and  what  the  term  interoperable  risk  management  would  entail  are  also  interesting  areas  for  investigation.  This 
subject  is  pursued  further  in  Risk  Management  Considerations  for  Interoperable  Acquisition  [Meyers  06b]. 

18.  For  more  information,  see  Process  Considerations  for  Interoperable  Acquisition  [Garcia  06]. 
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I  n  the  language  of  the  CM  M I  framework,  we  seek  more  automated  process  control 
where  control  can  be  exercised  even  by  autonomous  agents.19  Notice  that  the  goal 
here  is  similar  to  that  for  network-centric  operations:  the  benefit  gained  from  the  use 
of  automated  support  in  order  to  obtain  greater  sharing  of  information  that  permits 
collaborative  behavior. 

What  are  the  metrics  to  assess  programmatic  interoperability? 

I  n  discussing  our  definition  of  interoperability  (see  page  5),  we  mentioned  that  pre¬ 
ceding  it  with  the  phrase  "the  degree  to  which"  recasts  the  definition  in  terms  of  met¬ 
rics.  But  what  are  the  useful  metrics,  and  more  importantly,  how  would  they  be  used? 
Some  examples  of  possible  metrics  have  been  discussed  earlier  in  regard  to  schedule 
information  [Meyers  06c], 

What  are  the  impediments  to  achieving  programmatic  interoperability  due  to  the  legal 
and  regulatory  framework? 

The  environment  in  which  acquisition  occurs  is  influenced  by  many  things— from 
statutes  and  regulations  (e.g.,  Federal  Acquisition  Regulations)  toDoD  policy,  direc¬ 
tives,  and  business  practices.  Although  one  may  often  hear  that  the  legal  environ¬ 
ment  causes  problems  for  achieving  interoperability,  is  this  assumption  borne  out  by 
the  text  of  the  statutes  and  regulations  themselves?  And  if  it  is,  what  changes  to  the 
statues  and  regulations  need  to  be  made? 

What  approaches  lead  to  successful  programmatic  interoperability? 

All  of  the  preceding  issues  apply  to  the  goal  of  having  an  approach  to  achieve  pro¬ 
grammatic  interoperability.  I  n  order  for  that  approach  to  be  developed,  further  iden¬ 
tification  and  examination  of  all  issues,  as  well  as  their  integration,  is  necessary.  We 
anticipate  that  any  approach  must  address  the  three  fundamental  characteristics  of 
programmatic  interoperability:  communicating  entities,  information  shared,  and  col¬ 
lective  behaviors.  One  initial  approach,  whose  concepts  are  continuing  to  evolve,  has 
been  described  in  System-of -Systems  N avi gator:  An  Approach  to  M  anagi  ng  System-of- 
Systems  I nter operability  [Brownsword  06], 

How  does  interoperable  acquisition  affect  programmatic  interoperability? 

The  phrase  interoperable  acquisition  is  a  shorthand  for  interoperability  in  the  acqui¬ 
sition  process.  An  interoperable  acquisition  approach  would  address  programmatic, 
operational,  and  constructive  interoperability  aspects  that  are  necessary  to  produce 
systems  required  to  interoperate,  as  well  as  integration  of  these  aspects  of  i  nteropera- 
bility.  Some  work  in  inter  operable  acquisition  by  theSEI  has  been  done,  rangingfrom 
ontologies  to  models  (including  formal  models)  ([Meyers  05],  [Meyers  06b],  [Meyers 
06c],  [Smith  06]). 

How  extensible  are  research  questions  regarding  programmatic  interoperability  to 


1 9.  There  is  a  close  connection  here  with  process,  particularly  in  the  modeling  of  a  process  to  achieve  some  purpose 
such  as  interoperability  and  in  the  realization  of  that  model. 
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other  aspects  of  interoperability? 

Issues  related  to  interoperability  may  be  described  in  terms  of  a  programmatic,  a  sys¬ 
tem  construction,  or  an  operational  perspective.  However,  many  issues  apply  equally 
to  these  different  domains.  For  example,  the  issue  of  what  information  is  necessary  to 
be  shared  applies  to  each  domain.  To  the  extent  that  research  findings  regarding  pro¬ 
grammatic  i  nteroperabi  I  ity  can  be  appl  ied  to  other  aspects  of  i  nteroperabi  I  ity,  there  is 
the  opportunity  to  develop  more  general  approaches  for  the  resolution  of  issues. 
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4  Enlarging  the  Context 


The  preceding  discussion  focused  on  programmatic  interoperability,  which  is  but  one 
aspect  of  interoperability.  As  we've  shown,  the  SOSI  model  (see  Figure  3  on  page  8) 
also  includes  constructive  and  operational  interoperability  aspects.  To  achieve 
interoperability,  it  is  necessary  to  understand  not  only  each  aspect  but  also  the  inter¬ 
actions  between  them. 

4.1  OVERVIEW 

We  can  illustrate  the  orchestration  of  aspects  of  interoperability  in  a  system-of-sys- 
tems  context  by  extending  Figure  2  (from  page  8)  to  consider  multiple  organizations 
that  are  producing  systems  expected  to  interoperate  in  a  system-of-systems  context. 


System  A 


System  B 


•  •  O  denote  different  types  of  functions  (e.g.,  programmatic,  constructive  and  operational)  per¬ 
formed  by  the  indicated  corresponding  type  of  organization  shown  as  squares 


Figure  4:  Illustrating  Orchestration  of  Interoperability  Aspects  in  a  Multisystem  Context 


Figure  4  shows  the  functions  performed  and  the  organizations  involved  for  two  differ¬ 
ent  systems  that  are  expected  to  interoperate  in  a  system-of-systems  context.  As  in 
Figure2  on  page  8,  the  same  organization  can  perform  multi  plefunctions,  and  the 
same  function  can  be  performed  by  more  than  one  organization. 

In  this  figure,  however,  we  show  interoperability  relations  between  functions  within 
each  system  through  connecting  lines;  further,  other  connecting  lines  between  organi¬ 
zations  in  a  system  imply  interoperable  relations  that  result  from  the  related  func¬ 
tions.  Also,  heavy,  arrowed  lines  between  functions  performed  by  organizations  in 
different  systems  connote  that  it  is  necessary  to  orchestrate  the  activities  relevant  to 
each  system  in  a  way  that  some  larger  goal  is  achieved,  such  as  an  acquisition  man- 
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agement  organization  performing  a  risk  management  activity  and  needing  to  provide 
its  results  to  multiple  organizations. 

For  an  exampleof  this  orchestration,  consider  a  situation  in  which  multi  pie  systems 
are  being  developed  and  must  synchronize  their  schedules.  This  synchronization 
might  require  dealing  with  cost  factors  related  to  schedule  in  one  system  and  technol¬ 
ogy  factors  related  to  schedule  in  another  system.  The  orchestration  of  these  factors  is 
a  subject  that  must  be  considered  to  achieve  the  broader  goal  of  interoperability. 

4.2  PERSPECTIVES  ON  INTEROPERABILITY  INFLUENCES 

J  ust  as  each  aspect  of  interoperability  is  influenced  by  scope,  nature  of  agreements, 
and  shared  information  (as  detailed  in  Section  2.3),  so,  too,  is  the  orchestration  of 
those  aspects: 

•  scope  of  interaction 

An  increase  to  the  scope  of  interaction  means  that  many  more  organizations  par¬ 
ticipate  in  the  process.  The  number  and  type  of  functions  performed  by  these 
organizations  are  relatively  constant.  All  systems,  for  instance,  require  cost  esti¬ 
mation,  risk  management,  architecture,  and  testing.  However,  the  implementa¬ 
tion  of  those  functions  can  differ  as  the  number  and  type  (e.g.,  government  or 
industry)  of  organization  increase.  In  addition,  we  would  expect  changes  to  exist¬ 
ing  processes,  and  perhaps  even  new  processes,  are  necessary  to  achieve  pro¬ 
grammatic  interoperability. 

•  nature  of  agreements 

The  inclusion  of  more  organizations  means  greater  a  variety  of  agreements 
among  them.  F  or  example,  there  may  be  a  need  to  develop  an  agreement  among 
organizations  for  the  distribution  of  information. 

•  shared  information 

The  amount  of  information  that  must  be  shared  will  depend  on  the  functions  that 
are  performed.  For  example,  some  information  regarding  cost  management, 
schedule  management,  and  risk  management  is  a  likely  candidate.  With  agree¬ 
ments  in  place  regarding  how  the  information  may  be  distributed,  one  would 
expect  the  syntax  and  semanti  cs  of  such  i  nformati  on  to  be  shared.  One  mi  ght 
expect  that  such  information  would  be  specified  in  a  standard  that  can  be  used  by 
all  participants;  in  that  case,  thefunctions  shown  in  Figure4  would  collapse toa 
single  set.  This  scenario  assumes  that  the  specification  of  functions  performed  is 
sufficient  to  address  interoperability  considerations  among  those  functions, 
which  need  not  be  (and  in  our  experience  is  not)  the  case. 
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However,  as  we  pointed  out  in  Section  3.1,  it  is  not  simply  information  relevant 
to  the  functions  performed  that  is  of  interest.  The  sharing  of  that  information  is 
necessary  but  not  sufficient  to  achieve  collective  behavior  that  meets  the  goals  of 
acquisition  in  a  system-of-systems  context.  Knowledge  of  the  quality  of  informa¬ 
tion  shared  is  also  needed  to  assess  its  relevance  to  any  decisions  regarding  col¬ 
lective  behavior.20 

F  or  each  of  those  three  factors,  a  frame  of  reference  that  promotes  effective  mutual 
understanding  of  the  information  exchanged  is  needed.  For  example,  consider  the 
case  where  one  program  develops  cost  estimates  using  a  parametric  approach. 
Another  program  develops  cost  estimates  using  activity-based  costing.  I  n  order  for 
these  programs  to  share  cost  information  effectively,  they  must  first  share  a  frame  of 
reference.  The  mutually  compatible  frame  of  reference  permits  them  to  share  rele¬ 
vant  information  and  take  appropriate  collective  action  (behavior)  on  it.  Thus,  to 
share  cost  estimating  information,  the  programs  in  our  example  need  to  understand 
each  other's  approach  to  obtaining  estimates.  Without  a  common,  or  at  least  compati¬ 
ble,  frame  of  reference,  effective  sharing— and  understanding— will  not  be  possible. 

4.3  IMPLICATIONS 

The  orchestration  of  activities  and  decisions  needed  across  all  aspects  of  interopera¬ 
bility  is  a  subject  in  its  own  right.  We  are  suggesting  that  orchestration  makes  achiev¬ 
ing  programmatic  interoperability  more  complicated  than  one  might  at  first  think. 
Furthermore,  interoperable  acquisition  must  account  for  the  interaction  of  various 
aspects  of  interoperability.  Yet,  as  an  increase  in  scale  further  breaks  the  bonds  of 
coupling,  how  can  one  understand  and  address  the  new  environment? 


20.  If  one  takes  a  standards-based  view  on  relevant  information  that  could  be  shared  (such  as  risk  management),  it 
is  noteworthy  that  standards  documents  rarely,  if  ever,  discuss  the  means  by  which  information  may  be  obtained 
or  its  quality  assessed. 
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5  Summary 


The  term  interoperability  has  traditionally  been  used  in  the  context  of  operational 
systems.  This  report  suggests  a  broader  scope  for  this  term  that  encompasses  opera¬ 
tional,  constructive,  and  programmatic  aspects.  We  specifically  discuss  the  aspect  of 
programmatic  interoperability,  which  we  define  as 

programmatic  interoperability:  The  ability  of  a  set  of  communicating 
entities  engaged  in  acquisition  management  activities  to  (i)  exchange  speci¬ 
fied  acquisition  management  information  and  (ii)  to  operateon  that  acquisi¬ 
tion  management  information  according  to  an  agreed,  operational  semantics. 

We  propose  that  programmatic  interoperability  is  central  to  acquisition  in  a  system- 
of-systems  context.  When  we  orient  our  definition  toward  the  needs  of  the  acquisition 
community,  we  see  that  the  communicating  entities  need  to  achieve  a  shared  under¬ 
standing  about  acquisition  management  functions  (through  exchanging  information 
and  other  actions)  that  allows  them  to  act  collectively  in  the  context  of  a  thesystem- 
of-systems  environment.  The  purpose,  then,  of  programmatic  interoperability  is  to 
assure  that  a  collection  of  entities  can  successfully  operate  regarding  the  acquisition 
management  in  the  context  of  a  system  of  systems. 

I  n  this  report,  we  examine  a  number  of  topics  related  to  programmatic  interoperabil¬ 
ity  including  concepts,  examples,  and  research  questions.  Further,  we  argue  that  a 
connection  exists  among  all  three  aspects— operational,  constructive,  and  program¬ 
matic.  In  order  to  achieve  interoperability  in  the  operational  context  (which  is  the 
desired  state),  it  is  necessary  to  also  consider  programmatic  and  constructive  interop¬ 
erability  aspects.  In  addition,  it  is  necessary  to  consider  the  orchestration  of  activities 
and  decisions  across  all  aspects  of  interoperability. 
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Appendix  A  Definitions  of  Interoperability 


I  n  this  Appendix  we  present  a  number  of  approaches  to  the  definition  of  the  term 
interoperability.  For  example,  I E  EE  has  the  foil  owing  definitions  [IEEE  00]: 

the  ability  of  two  or  more  systems  or  elements  to  exchange  information  and  to 
use  the  information  that  has  been  exchanged 

the  capability  for  units  of  equipment  to  work  together  to  do  useful  functions 

the  capability,  promoted  but  not  guaranteed  by  joint  conformance  with  a 
given  set  of  standards,  that  enables  heterogeneous  equipment,  generally  built 
by  various  vendors,  to  work  together  in  a  network  environment 

the  ability  of  two  or  moresystems  or  components  to  exchange  information  in  a 
heterogeneous  network  and  use  that  information 

DoD  also  uses  multiple  definitions  of  interoperability,  all  of  which  are  based  to  some 
degree  on  the  definitions  developed  by  I EEE .  For  example,  one  definition  is  [DoD  00] 

1.  The  ability  of  systems,  units,  or  forces  to  provide  services  to  and  accept  ser¬ 
vices  from  other  systems,  nits,  or  forces  and  to  use  the  services  so  exchanged  to 
enablethem  to  operate  effectively  together.  2.  Thecondition  achieved  among 
communications-electronics  systems  or  items  of  communications-electronics 
equipment  when  information  or  services  can  be  exchanged  directly  and  satis¬ 
factorily  between  them  and/or  their  users.  The  degree  of  interoperability 
should  be  defined  when  referring  to  specific  cases. 

Item  2  of  the  preceding  definition  was  later  modified  in  the  foil  owing  manner  in  con¬ 
nection  with  they  oint  Requirements  Oversight  Counci  I  [DoD  02]: 

2.  Thecondition  achieved  among  communications-electronics  systems  or 
items  of  communications-electronics  equipment  when  information  or  services 
can  be  exchanged  directly  and  satisfactorily  between  them  and/  or  their  users. 

The  degree  of  interoperability  should  bedefined  when  referring  to  specific 
cases.  For  the  purposes  of  this  instruction,  thedegreeof  interoperability  will 
be  determined  by  the  accomplishment  of  the  proposed  information  exchange 
requirements  fields. 

Further,  in  the  context  of  they  oi  nt  Capabilities  I  ntegration  Development  System 
[DoD  05],  the fol lowing  appeared: 

The  abi  I  ity  of  systems,  units  or  forces  to  provide  data,  information,  materiel 
and  services  to  and  accept  the  same  from  other  systems,  units  or  forces  and  to 
usethedata,  information,  materiel  and  servi ces  so  exchanged  toenablethem 
to  operate  effectively  together.  Information  technology  and  National  Security 
Systems  i  nteroperabi  I  ity  i  nd  udes  both  thetechnical  exchange  of  information 
and  the  end-to-end  operational  effectiveness  of  that  exchanged  information  as 
required  for  mission  accomplishment. 

I  n  the  context  of  the  Global  Information  Grid,  the  fol  I  owing  is  found  [DoD  01]: 

(1)  Ability  of  information  systems  to  communicate  with  each  other  and 
exchange  information.  (2)  Conditions,  achieved  in  varying  levels,  when  infor¬ 
mation  systems  and/  or  their  components  can  exchange  i n  for mati on  directly 
and  satisfactorily  among  them.  (3)  T  he  abi  I  i  ty  to  operate  software  and 
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exchange  i nformati on  in  a  heterogeneous  network  (i.e,  one  large  network 
made  up  of  several  different  local  area  networks).  (4)  Systems  or  programs 
capable  of  exchanging  information  and  operating  together  effectively. 

Thell.  S.  Congress  also  has  interest  in  interoperability.  For  examplein  theE-Govam- 
mentAct  of  2002  [USC  02]  onefinds  thefollowing: 

7  nter  operability'  means  the  ability  of  different  operating  and  software  sys¬ 
tems,  applications,  and  services  to  communicate  and  exchange  data,  in  an 
accurate,  effective,  and  consistent  manner. 

Of  interest  to  the  DoD  are  statements  regarding  interoperability  that  are  specified  in 
law,  in  particular  Title  10  is  the  U.S.  Code  [USC  04],  Although  the  term  interopera¬ 
bility  is  not  defined  there,  it  is  used  in  a  number  of  ways: 

•  research  and  development  projects  (10  USC  §  2358) 

•  establishing  standards  and  cooperative  research  work  with  NATO  (10  USC  § 
2350B  and  §  2457) 

•  responsibility  of  the  Chief  I  nformati  on  Office  to  ensure  interoperability  (10  USC 
§  2223) 

•  acquisition  authority  for  joint  experimentation  by  the  Unified  Combatant  Com¬ 
mand  (10  USC  §  485) 

•  assessment  of  capabilities,  adequacy,  and  interoperability  of  coalition  forces  (10 
USC  §  153) 

Two  points  are  relevant  about  a  perspective  of  interoperability  based  on  Title  10. 
First,  one  must  be  careful  in  so  strict  a  view,  because  the  word  integration  (or  a  syn¬ 
onym)  may  be  used  instead  of  interoperability.  Sometimes  interoperability  is 
implied.21  Second,  and  perhaps  of  more  practical  significance,  one  cannot  forget  all 
the  regulations,  policies,  and  practices  that  are  later  implemented  by  DoD  in  response 
to  the  language  in  Title  10. 

We  can  summarize  an  examination  of  the  definitions  of  interoperability  by  notingthe 
following  point:  Theterm  interoperability  has  been  traditionally  used  in  thecontext  of 
an  operational  system. 


21 .  One  gains  an  interesting  perspective  by  examining  the  language  in  Title  10.  For  example,  in  1 0  USC  §  1 24,  the 
DoD  is  designated  as  the  single  lead  agency  for  the  Federal  Government  for  detection  and  monitoring  the  transit 
of  illegal  drugs  into  the  U.S.  The  word  interoperability  does  not  appear  in  the  that  text.  However,  in  Pub.  L.  1 06- 
65  §  1043  (October  23,  1992),  the  rationale  for  DoD  assuming  lead-agency  responsibility  is  explicitly  stated  as 
“(3)  to  promote  commonality  and  interoperability  between  counter-drug  detection  and  monitoring  systems  in  a 
cost-effective  manner.  .  .  .”  Thus,  from  Public  Law  to  Title  10,  consideration  of  interoperability  went  from  explicit 
to  implicit.  This  migration  should  not  be  viewed  as  diminishing  its  importance  [USC  04], 
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